In automotive electronic control units (ECUs), higher performance requirements have led to the use of higher-end central processing units (CPUs), which are typically part of embedded microcontroller units (MCUs) that include on-chip instruction and data caches, high-speed random access memory (RAM) and flash read-only memory (ROM). As various automotive subsystem designers have migrated to higher-end CPUs, it has become increasingly difficult to provide visibility for logic analyzer, processor emulation and calibration without compromising performance of a given ECU. For example, in MCUs implemented with an internal bus for core operations and an external peripheral bus for I/O operations, the internal bus cannot typically be coupled to external pins, thus, preventing sufficient visibility to perform complete logic analysis.
In general, system developers require development tools to perform logic analysis, run control, and calibration. As is well known, logic analysis typically pertains to accessing program trace information to correlate program flow of the ECU to real-world interactions. In general, the developer also needs to perform logic analysis to retrieve information on how data flows through the ECU and to understand what system resources are creating and accessing the data. Finally, logic analysis is directed to determining whether the software of the ECU is meeting the required performance standard with acceptable impact to the ECU under test. For run control, a developer normally needs to be able to query and modify all registers and memory locations in the ECU and needs support for breakpoint features provided by debug interfaces, as either hardware or software breakpoints depending upon the architecture of the CPU.
Traditionally, software development of ECUs has been supported through direct access to CPU buses, via bus lines that could be multiplexed with an I/O port of an MCU. However, with CPUs that implement a two bus system (internal/external) there is generally less or no external bus visibility of internal data or instruction flow and/or a reduction in performance of the MCU if flow information is shown in real-time on an external bus, such as the use of a background debug port.
The requirement for higher performance automotive ECUs has prompted many designers to move from microprocessor based systems, where the CPU buses are exposed and available for instrumenting, to microcontroller based systems, where the CPU buses are internal and are not available for instrumenting without significant cost and pin count penalties. In addition, many of the microcontroller parts have wider buses, e.g., 32 to 64 bits, which amplify the above-mentioned penalties. Increasingly, designers have been challenged with providing visibility needed for calibration, logic analysis and processor emulation while keeping costs contained and not compromising performance of MCUs with higher-end CPUs.
When multiple bus embedded MCU systems are employed, it is even more difficult for external tools (i.e., logic analyzers or in-circuit emulators (ICEs)) to determine the actual instruction being executed as there is no external or off-chip visibility of the program address bus. As higher-end microprocessors are run at higher frequencies, a typical ICE cannot implement memory emulation and real-time diagnostics as the available timing budget is simply too short to facilitate these functions. In addition, deep instruction pipelines, on-chip caches and RISC speculative architectures generally make it difficult to determine what instructions were fetched and which were actually executed.
In general, breakpoints allow a program to be stopped at a specified event, which can be specified as a c(ode execution at a specified address or as a data access (i.e., a read or write) to a specified address with a specified value (e.g., when 0FFF(h) is written to address 09876543). Watchpoints, which are similar to breakpoints, provide a message to a debug tool when a watchpoint occurs, as opposed to halting the CPU of the MCU.
Recently, to address some of these concerns, a number of manufacturers have joined together to create a standard debug interface for embedded control applications known as NEXUS™ (previously known as the global embedded processor debug interface standard (GEPDIS)). The NEXUS™ debug interface can be used to connect tools to an embedded system to facilitate run-time control (i.e., debugging), code execution trace capture and data access capture, calibration (data access on-the-fly), logic analysis and rapid algorithm development.
The NEXUS™ interface uses a branch trace capture and instruction cycle counting technique to compress the information needed to reconvolve the actual trace of the program execution. In this manner, the executed code's address information is provided via the debug module's communication port at branch or exception instructions only and the external debug tool interpolates or reconvolves the program trace for sequential (i.e., non-branch) instructions from a local image of the code memory contents. Although this increases cost and complexity to the external instrumentation tool it does allow the debug/instrumentation tool to perform reconstruction of the program flow. In general, the NEXUS™ interface provides a limited capability for the debug tool to track real-time data accesses to various memory locations. The trace can be restricted by specifying a specific range and a specific access type (i.e., read or write), however, this data is not directly correlated to the instruction flow.
As such, current debug ports only provide limited visibility into the operation of an MCU. Thus, it would be desirable to provide a technique for capturing information on the operation of an MCU that is cycle-by-cycle accurate.